Handling of interrupt actions in an interrupt-driven real time data processing system can significantly affect the system's performance characteristics. Software must interrogate various hardware subsystems to first determine the cause of the interrupt and then gather information from the interrupt source hardware subsystem to determine what action or actions to take. When several interrupts exhibit the same interrupt priority level, the task of determining which interrupt source to handle first, while also making sure that no interrupt remains pending for an excessively long time, may add considerable processing overhead to the software code which controls performance of tile interrupt action.
In a typical prioritized interrupt system, various events can occur which give rise to an interrupt. Interrupt signals (i.e., "requests") arising from such events are assigned predetermined priority levels, ranging from high priority to relatively low priority. A high priority interrupt request can interrupt regular processing as well as the processing of a low priority interrupt request. Conversely, an interrupt request of low priority can interrupt regular processing, but cannot interrupt the processing of an interrupt request of equal or higher priority.
A commonly utilized interrupt processing method causes interrupt requests to be queued and then executed on a one-by-one basis, until all interrupts in the queue have been exhausted. The processor, upon accessing an interrupt request from the queue, polls a plurality of connected subsystems to determine which subsystem initiated the interrupt request and then determines from that subsystem, the necessary facts to enable execution of the requested interrupt action. This action is time-consuming and exacts a high processing overhead for tile performance of interrupts.
The prior art is replete with teachings of interrupt handling methods and systems. Dodd et al. in "Processor Interrupt Buffer Mechanism" IBM Technical Disclosure Bulletin, Vol. 15, No. 1, June 1972, pp. 104-105, describes a system wherein interrupts are listed in a variable-length queue in a local storage address space of an associated processor. Interrupts are stored in the queue in a first-in, first-out sequence. In a similar vein, Eden in "Intelligent Input/Output Interrupt Processing" IBM Technical Disclosure Bulletin, Vol. 17, No. 7, December 1974, pp. 1915-1916, describes a listing of interrupt requests in a queue stack. Eden further describes the subsequent processing of the interrupt requests at a later, more desirable point in time. Eden also indicates that the stacked interrupt requests can be subsequently processed in an order which is different from the physical sequence in which they were received.
Youngblood (U.S. Pat. No. 4,980,820) describes an interrupt-driven data processor wherein an interrupt handler identifies and queues individual work items that must be performed to completely satisfy a received interrupt request. The interrupt request is not necessarily performed immediately and can be performed at a future time without affecting processor performance. By having the work items required for the interrupt action in a queue, the processor operation is interrupted for a minimum amount of time while servicing the interrupt request. Further, the work items in the queue are prioritized for execution.
Beardsley et al. (5,313,640) describes a system for responding to multiple different types of interrupts. A selected type of interrupt, for a next interrupt to be received by a storage subsystem controller, is then determined in response to a determination of the current state of the controller. A particular state associated with the occurrence of the selected type of interrupt is then determined. Reversible processing, associated with the particular state, is then initiated prior to receipt of the next interrupt.
Chang et al., in U.S. Pat. No. 5,325,536, describe an interrupt handling system which includes a plurality of interrupt queues. Each queue is pre-established and holds a predetermined number of interrupt pointers, all of which indicate interrupt actions that are to be handled by one of a plurality of interrupt handlers. Each interrupt handler is a separate routine for carrying out a predefined process corresponding to a particular group of events. Thus, all events giving rise to an interrupt listed in one queue are handled by one sub-routine call to an associated interrupt handler. In other words, when the interrupt pointers listed in a queue are called for execution, only a single entry into the associated interrupt handler routine is required to enable all interrupt requests in the queue to be executed.
During operation of a data processing system, a number of events may occur which will eventually require the execution of an interrupt, but where the exact time of execution of the interrupt is not critical. When, however, that interrupt is eventually executed, it is desirable to reduce, by as much as possible, the processing overhead required to execute the interrupt.
Accordingly, it is an object of this invention to provide an improved method and apparatus for handling interrupt actions wherein data processing overhead required to enable interrupt execution is minimized.
It is another object of this invention to provide an improved method and apparatus for handling of interrupts which enables non-time critical interrupts to be enqueued and to be executed at a later time.
It is yet another object of this invention to provide an improved method and apparatus for handling of interrupts wherein an indefinite-length queue of interrupt requests can be dynamically constructed and subsequently executed in a manner so as to minimize processing overhead.